Telecommunications services provided over an IP Connectivity Access Network (IP-CAN) can be subject to charging and policy control mechanisms. This includes Quality of Service (QoS) control. Accordingly, some telecommunications systems incorporate Policy and Charging Control (PCC) architectures to provide this control. 3GPP TS 23.203 V8.1.1 describes such a PCC architecture in respect of packet flows in an IP-CAN session established by a user terminal through an Evolved 3GPP telecommunications system, including both 3GPP accesses (GERAN/UTRAN/E-UTRAN) and Non-3GPP accesses. FIG. 1 illustrates schematically an example of the PCC architecture described in 3GPP TS 23.203 that comprises a Policy and Charging Enforcement Function (PCEF), a Bearer Binding and Event Reporting Function (BBERF), a Policy and Charging Rules Function (PCRF), an Application Function (AF), an Online Charging System (OCS), an Offline Charging System (OFCS) and the Subscription Profile Repository (SPR).
The PCEF is a functional entity that behaves as a Policy Enforcing Point (PEP) for enforcing decisions instructed by the PCRF and the OCS. The PCEF captures any user and signalling traffic, and analyzes that traffic to identify the user and to capture details of the service(s) being used. The PCEF can then communicate this information to the PCRF over the Gx interface, to the OCS over the Gy interface and to the OFCS over the Gz interface. The PCEF is preferably co-located within the gateway node implementing the IP access to the PDN. As such, in a GPRS core network the PCEF is located within the GPRS Gateway Support Node (GGSN), whilst in the case of a CDMA2000 network the PCEF may be located in a Packet Data Serving Node (PDSN).
The OCS provides authorization for the usage of network resources based on the provisioned data and the user activity information it receives from PCEF. This authorization must be granted by the OCS prior to the actual resource usage. When receiving a network resource usage request, the network assembles the relevant charging information and generates a charging event towards the OCS in real-time. The OCS then returns an appropriate resource usage authorization over the Gy interface. The resource usage authorization may be limited in its scope (e.g. volume of data or duration) therefore this authorization may have to be renewed from time to time as long as the user's resource usage persists. The OCS can support time, volume and event-based charging.
The AF is an element offering applications that require policy and/or charging control of the IP-CAN user plane behaviour. The AF communicates with the PCRF over the Rx interface to transfer dynamic session information, required for PCRF decisions as well as to receive IP-CAN specific information and notifications about IP-CAN bearer level events. One example of an AF is the P-CSCF of the IP Multimedia Core Network (IM CN) subsystem. In the case of a P-CSCF, the information communicated over the Rx interface is derived from the P-CSCF session information (e.g. SDP when SIP is used for signalling) and it mainly includes media components. A media component comprises a set of IP flows, each of which is described by a 5-tuple, the media type and required bandwidth.
The PCRF can be implemented as a standalone node and behaves as a Policy Decision Point (PDP), or Policy Server (PS), that stores user data related to QoS enforcement, access control lists, etc. The PCRF provides policy and charging control for the media components negotiated between the user terminal and the AF. The PCRF provides network control regarding the service data flow detection, gating, QoS and flow based charging (except credit management) towards the PCEF. The QoS information that PCRF downloads to the PCEF includes the QoS class identifier (authorized QoS class for the service data flow), the Allocation and Retention Priority (ARP) and authorized bitrates for uplink and downlink. Once a decision is taken in PCRF, this decision is indicated to the PCEF by means of the Gx interface.
The SPR contains all subscriber/subscription related information needed for subscription-based policies and IP-CAN bearer level charging rules by the PCRF. The Sp interface allows the PCRF to request subscription information related to the IP-CAN transport level policies from the SPR based on a subscriber ID and other IP-CAN session attributes.
Network operators offer a variety of different types of subscription to users, each of which can have a different QoS and/or usage limits. For example, one subscription type may provide the user with a bandwidth limit of 1 Mbps for the first 1 Gb of data, after which the bandwidth is then downgraded to 128 Kbps. An alternative subscription type may provide a bandwidth limit of 3 Mbps for the first 5 Gb of data, after which there is no access to any services other than the operators portal. Therefore the QoS level received by the user will depend on what he/she is willing to pay. Although the examples above only define the bandwidth limit QoS parameter, the user's subscription type can also define other QoS parameters, such as the QoS Class Identifier (QCI), traffic delay, etc.
For certain types of services there may be a preferred or required minimum QoS. For example in a video conference it is essential to provide a sufficiently high bandwidth to all the participating users. FIG. 2 is an example signalling flow diagram of a video conference negotiation in an IM CN subsystem. In this example, two users are negotiating a video conference. The subscription of one of the users provides a bandwidth restricted below the QoS required for the video conference, such that the negotiation fails and the session is aborted. The steps performed are as follows:                A1. A SIP INVITE is sent from the originating user terminal (UE A) to a terminating user terminal (UE B). The SIP INVITE is routed via P-CSCF A associated with UE A to a Telephony Application Server (TAS) and onto P-CSCF B associated with UE B.        A2. UE B returns a 183 Session Progress message to P-CSCF B.        A3. P-CSCF B then sends an Authenticate and Authorize Request (AAR) message to PCRF B to authorize the required QoS.        A4. In this example, PCRF B does not authorise the QoS because the subscription of user B of UE B does not allow the QoS required for the session (e.g. if the user's maximum bandwidth=1 Mbps and the video conference requested bandwidth=2 Mbps). PCRF B sends the rejection to P-CSCF B in an Authenticate and Authorize Answer (AAA) message.        A5. The P-CSCF B sends a BYE message to the UE A and UE B to inform them that the session has been terminated.        
Alternatively, it could be the case that, despite the restricted bandwidth, the service is allowed. However, without the desired QoS, it is likely that the service experienced by both users will be poor. In a further alternative, both users may initially negotiate and agree a certain QoS. However, during the session one of the users may be downgraded to a lower QoS, for example, the user may have exceeded their usage limit. In this case, whilst the session is not interrupted, the service will be degraded and this degradation will be perceived by both users.
In summary, whilst the limitations on the QoS available to a user, due to the restrictions of their subscription, will limit the services available to that user, they may also limit the services or QoS available to other users who wish to communicate with that user.